home *** CD-ROM | disk | FTP | other *** search
/ Scene Storm / Scene Storm - Volume 1.iso / coding / c / xprzmodem_zedzap / xprzedzap.doc < prev    next >
Text File  |  1995-11-05  |  6KB  |  132 lines
  1.  
  2.    To start off, the xprzedzap.library is just a slightly modified
  3. xprzmodem.library. The xprzedzap.library uses the 2.10 version of the
  4. xprzmodem.library as its base and uses the 2.50 version for the 32bit
  5. CRC routines. The reason the 2.50 version is not used as a base is
  6. that it does not compile correctly under SAS/C 5.10a. After analysis
  7. on the source code to both versions, they appear to be identical ex-
  8. cept for the 32bit CRC routines.
  9.    It appears, that there might be a bug in the xprzmodem.library
  10. when the ZFIN is not acknowledged by the receiver when one is sending
  11. a file, but I believe that this is not caused by the library, and is
  12. instead caused by the comm. program accessing the library.
  13.    The changes from zmodem to zedzap are as follows. 1) The maximum
  14. packet size can now be set with a maximum/default at 8192. This will
  15. vary when sending and will be static when receiving. When sending
  16. the maximum packet size will be baud rate dependant, and the size is
  17. calculated with the formula MAX_PACKET = (BPS_RATE * 8192 / 9600).
  18. You can specify a limit for the maximum packet size with the M op-
  19. tion, but it only influence the packet size if it is smaller than
  20. MAX_PACKER or if one is receiving a file (NOTE: It should allways be
  21. set to 8192 if one is receiving a file... But the option in there to
  22. limit it to less). Also, the IO Buffer for reading/writing to/from
  23. the disk must be equal to twice the maximum packet size (or the ma-
  24. ximum packet size will automatically be decreased). 2) One can start
  25. and end a transfer if there are no files to be sent. If this option
  26. in used and no files are sent, then most BBS programs will report
  27. that the upload was unsuccessful (experienced this when testing the
  28. library).
  29.  
  30. All options must be in the following order (to be sent by one's comm.
  31. program): T(YN?C),O(YNRS),B(num),F(num),E(num),A(YN),D(YN),K(YN),
  32.           S(YN),R(YN),C(num),N(YN),M(num),P(string)
  33.  
  34. new options:
  35. N = Send if there are no files                            Def: Y
  36. M = Set maximum packet size ((M <= 8192 )&&(B >= M * 2))  Def: 8192
  37. C = Set Pseudo BPS Rate (if you are have you BPS rate locked, this
  38.     will make the library use this BPS rate to calculate the maxi-
  39.     mum packet size). I it is set below 300 or above 56800 then it
  40.     will be ignored. If it is left out, it will also be ignored.
  41.     This could be used in the future by Welmat if the BPS rate is
  42.     locked and a connection of 2400BPS is made with the serial port
  43.     at 19200.
  44.  
  45. -=> Please see Codes.Doc for changes to the result messages! <=-
  46.  
  47. Example: (for coorect operation on Fidonet)
  48. TN,ON,B16,F0,E30,AN,DY,KN,SN,RN,C2400,NY,M8192,Pmail:inbound
  49. Features:
  50. -Send in binary mode
  51. -Append .dup[n] to duplicate files
  52. -File IO buffer set to 16k (should be M * 2 = 8192 * 2 = 16384 = 16k)
  53. -Do Not Use Frames
  54. -Allow a maximum of 30 errors to occur during transfer
  55. -Do not download automatically
  56. -Do not keep partial files (because of option O)
  57. -Do not send full path
  58. -Do not use received path
  59. -We are using the maximum packet size that is associated with 2400BPS
  60.  (in this case 2048, so the M8192 would not really make a difference.
  61.  This should be set after connecting. If this is not specified, then
  62.  the normal BPS rate be used in the calculation of the maximum packet
  63.  size)
  64. -Start transfer even if there are no files to be sent
  65. -Set maximum packet size to 8192 (this might be set lower if the BPS
  66.  rate is below 9600 or if the file IO buffer is smaller than 16k. This
  67.  should be kept at 8192 at all times, but the option is there to set
  68.  it to a lower level)
  69. -Receive all files into the directory mail:inbound/
  70.  
  71. Problems:
  72. -If file requests are received and are not replied to in such a way
  73.  that the *.REQ file is deleted (or renamed), then the node that sent
  74.  the *.REQ file will not be able to send the file again with that
  75.  name, as it will automatically be named *.REQ.DUPn by the protocol,
  76.  or original *.REQ file will be overwritten. This is all specified
  77.  with the 'O' option ('OS' would make the *.REQ file get skipped all-
  78.  together).
  79. -The same goes with *.OUT,*.HUT, and *.CUT files (but since these are
  80.  barely used in the first place...)
  81.  
  82. This XPR library has been tested with VLT and Welmat.
  83.  
  84. Credits:
  85. -Chuck Frosberg for the original ZMODEM specs
  86. -Rick Huebner for the original xprzmodem.library (--> v2.10)
  87. -William M. Perkins for the 32bit CRC improvements (2.50)
  88. -Yves Konigshofer for the slight changes to allow ZedZap-type transfers
  89.  
  90.    Address Comments To:
  91.    Yves Konigshofer
  92.    1:109/456.0@FidoNet
  93.    (301)469-YVES
  94.            [9837]
  95.  
  96. ----
  97. Updates - Russell McOrmond
  98.  
  99.  
  100. -----------------------------------------------------------------------
  101. Bug Fixes - Yves Konighofer
  102.  
  103. 20 Nov. 1992
  104.  
  105. Welmat [rwm- current beta's, not a valid concern] does not use v->Baud 
  106. so a packet size of 2400 was assumed in the
  107. zgethdr() routine. This works just fine for 2400bps transfers, BUT at
  108. high speeds with large 8192 byte blocks it would be almost fatal for an
  109. error to occur that messes up the header since only the next 2400 bytes
  110. would be checked. This has been fixed so that 8192*2 characters will be
  111. read instead of 2400 before the "garbage count" becomes too large. This
  112. is because we CANNOT assume that the sending will use a smaller packet
  113. than 8192 bytes (even at only 1200bps). Also, be allowing 2*8192 bytes
  114. to be read, we increase the likelyhood of hitting the next header if
  115. the fist is messed up and becomes longer due to line noise (thus one
  116. less garbage count error would be reported). Alas, both ways will re-
  117. quire a resync to be performed.
  118.  
  119. The order of the 'case' statements in the rzfile() routine has been
  120. changed slightly so that it will not send two Attention sequences when
  121. a bad header is followed be a bad packet.
  122.  
  123. A few result codes for errors have been changed slightly. If you speci-
  124. fy that an already existant file should be skipped, the procheader()
  125. routine will report ZSKIP instead of ERROR. ZDCO has also been updated
  126. to show that the carrier has been dropped. While none of the XPR inter-
  127. faces that I know support a carrier check, this result has been pro-
  128. vided. [rwm - All XPR interfaces that I know of return (-1) from
  129. an xpr_sread() to indicate a carrier drop.  I know that both TERM
  130. and Welmat support this properly]
  131. -----------------------------------------------------------------------
  132.